Use send_help to ensure that our help command is correctly invoked#949
Conversation
After the refactoring of the help command, we need to use the built-in
method of calling the help command: `Context.send_help`. As an argument,
the qualified name (a string containing the full command path, including
parents) of the command can be passed.
Examples:
- await ctx.send_help("reminders edit")
This would send a help embed with information on `!reminders edit` to
the Context.
- await ctx.send_help(ctx.command.qualified_name)
This would extract the qualified name of the command, which is the full
command path, and send a help embed to Context.
- await ctx.send_help()
This will send the main "root" help embed to the Context.
f73489f to
4e24e9c
Compare
|
A Quick comment, would it be more efficient to pass in |
The docs don't mention support for passing in a |
Probably, I'll take a look if that works for every case. |
As @mathsman5133 pointed out, it's better to use the `Command`-instance we typically already have in the current context than to rely on parsing the qualified name again. The invocation is now done as: `await ctx.send_help(ctx.command)`
|
I accidentally hit |
lemonsaurus
left a comment
There was a problem hiding this comment.
Yes. This change is an improvement anyway, the previous approach was fighting the framework.
kwzrd
left a comment
There was a problem hiding this comment.
Appears functional and I agree that this is an overall improvement.
Currently, we're invoking our help command manually like this:
However, unfortunately, this fails when the command callback function is decorated, leading to exceptions like:
See Sentry issue: BOT-4T
The solution is to use the way of invoking the help command built built into
discord.py:ctx.send_help, as the recent refactoring of the help command made our custom help command compatible with thatContextmethod.